Identification information protection method in wlan inter-working

ABSTRACT

By introducing a hierarchical encryption scheme and the use of asymmetric cryptography, the critical information in message exchanges is concealed from unauthorized entities. This helps greatly in preventing man-in-the-middle attacks faced by inter-working. In addition, access control is conducted by introducing a network structure having a rule interpreter that is capable of mapping general rules to WLAN specific commands. It obviates the needs for mobile user&#39;s home network to understand information about every WLAN it is inter-worked with. A common interface independent of WLAN technologies could be used by the home network for all the WLANs. The above conception provides a solution to the problems of the protection of user identification information and access control in the inter-working of WLAN.

FIELD OF THE INVENTION

The present invention pertains to the field of wireless datacommunication, and more particularly, this invention relates to theprovision of service in the wireless LAN (Wireless Local Area Network:WLAN) environment to the mobile user coming from other networks. Theinvention is used for the control of the access of the resource of theWLAN for the mobile users, in particular, the authentication,authorization, and accounting issues.

BACKGROUND ART

A wireless LAN is a flexible data communications system implemented asan extension to, or as an alternative for, a wired LAN. Using radiofrequency (RF) technology, wireless LANs transmit and receive data overthe air, minimizing the need for wired connections. By this means,wireless LANs combine data connectivity with user mobility. WirelessLANs have gained strong popularity in a number of vertical markets,including the health-care, retail, manufacturing, warehousing, andacademia. These industries have profited from the productivity gains ofusing hand-held terminals and notebook computers to transmit real-timeinformation to centralized hosts for processing. Today wireless LANs arebecoming more widely recognized as a general-purpose connectivityalternative for a broad range of business customers.

Wireless LANs offer much higher access data rates than do cellularmobile networks, but provide limited coverage—typically up to 50 metersfrom the radio transmitter. While public networks, e.g. GSM/GPRS andWCDMA offer widespread—typically nationwide—coverage. In order toprovide integrated service to the subscriber of both WLAN and publicnetworks, the WLAN must inter-work with other WLANs or cellular mobilenetworks.

A few standardization groups have started the study on the WLAN and 3Gnetwork inter-working issues. In 3GPP [Non-patent document 1], afeasibility study report has been released. This document defined thescope for the inter-working, and also the usage scenarios. Theinter-working scenarios are described in detail, and are divided intosix stages, from the simplest “common billing and customer care” to themost sophisticated “access to 3GPP CS services.” A few requirements forthe inter-working scenarios were given. Also, in a function andrequirement definition document [Non-patent document 3], the detailedrequirements for the functions, e.g. authentication, access control, andcharging, are discussed. Some methods for the authentication areinvestigated. They are mainly based on the UMTS AKA, and GSM SIMsolutions. No solution about the other aspects, e.g. access control, andcharging, is given. These documents are not finalized yet, and there areworking groups actively working on them.

A draft is available for using the AKA schemes over the EAP method[Non-patent document 4]. It enables the use of third generation mobilenetwork authentication infrastructure in the context of wireless LAN andIEEE802.1x technologies through the EAP over wireless. The problem withit is that it requires UMTS subscriber identity module or similarsoftware modules. This might not be available for all the mobiledevices. Also, the EAP-AKA scheme would require the user's IMSI inclear-text be sent to the EAP server when the user gets first connectionto it. This might leak the user's identification information to entity(a mobile user coming from other network, etc.) that is ear-dropping themobile terminals. The scheme uses a challenge message-responsemechanisms and symmetric cryptography for the authentication.

The IEEE is also working on the authentication issues for the WLAN. TheIEEE802.1x [Non-patent document 5], which introduced the EAPOL, gives asolution for using EAP [Non-patent document 6] on top of the Ethernetenvironments. The problem with it is that it only works for the Ethernetor the FDDI/Token Ring MACs. To make it work on other technologies, someadaptations must be made. This only provides a basic way for using theEAP methods for authentication, and the actual solution still relies onthe individual EAP methods deployed. Also, this work does not addressany other aspects in the inter-working, e.g. access control, QoS, etc.

IETF has an AAA working group [Non-patent document 7] that focuses onthe developments of requirements for authentication, authorization, andaccounting for network access. They base the work on the Diametersubmissions. There are other working groups also working on issuesrelated to inter-working, e.g. SEAMOBY group [Non-patent document 8],and SIPPING group [Non-patent document 9]. But most of them are assumingIP based environments, and are not specific to the WLAN problems, andthere is not a concrete solution for all the problems.

In order for the WLAN to provide service to the mobile terminal, somedecisions must be made based on the subscription information of themobile terminal. When the mobile terminal requesting for services isregistered under another administrative domain than the WLAN's, thisinformation must be obtained from the mobile terminal's home domain. Butin most of the cases, the information is confidential, and is notallowed to be disclosed to the WLAN due to the lack of trustrelationships. Therefore, the home domain must have a way of providecrucial information for the WLAN to operate without compromising theconfidentialities. Besides this, some networks would also require toprovide protection of the mobile terminal's location information.Namely, the identification information of the mobile terminal shouldalso be concealed in the message exchanges between the WLAN and mobileterminal.

The service provision in the WLAN requires certain underlying technologyspecific parameters. It is not feasible or sometimes impossible for themobile terminal's home network to identify this information. Therefore,an entity in the WLAN must be able to translate the control informationfrom the home network to local control messages.

Since the mobile terminal's subscription information is stored in itshome domain, and WLAN do not have direct access to it, reports must besent to the home domain from time to time to gain real-time monitoringand control of the service provided to the mobile terminal. Thesereports would generate a heavy traffic when large number of mobileterminals present. This would decrease the accuracy of the real-timecontrol. Therefore, it is desired to have the WLAN to do some processinglocally.

It is noted that, in this specifications, [Non-patent document 1] refersto 3GPP, http://www.3gpp.org, [Non-patent document 2] refers to“Feasibility study on 3GPP system to Wireless Local Area Network (WLAN)inter-working (Release 6)” 3GPP TR 22.934V1.1.0 (2002-05),http://www.3gpp.org/specs/specs.html, [Non-patent document 3] refers to“3GPP system to Wireless Local Area Network (WLAN) inter-working;Functional and architectural definition (Release 6)” 3GPP TR 23.934V0.3.0 (2002-06), http://www.3gpp.org/specs/specs.html, [Non-patentdocument 4] refers to “EAP AKA Authentication”,http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-03.txt,[Non-patent document 5] refers to “Standard for Local and metropolitanarea networks: Port-Based Network Access Control” IEEE Std 802.1X-2001,http://www.ieee.org, [Non-patent document 6] refers to ExtensibleAuthentication Protocol,http://www.ietf.org/html..charters/eap-charter.html, [Non-patentdocument 7] refers to Authentication, Authorization, and Accountinggroup, http://www.ietf.org/html.charters/aaa-charter.html, [Non-patentdocument 8] refers to SEAMOBY (Context Transfer, Handoff CandidateDiscovery, and Dormant Mode Host Altering) group,http://www.ietf.org/html.charters/seamoby-charter.html, [Non-patentdocument 9] refers to SIPPING (Session Initiation ProposalInvestigation) group,http://www.ietf.org/html.charters/sipping-charter.html, [Non-patentdocument 10] refers to DIAMETER,http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-08.txt,[Non-patent document 11] refers to “Applied Cryptography” SecondEdition, Bruce Schneiner, Wiley, 1996, [Non-patent document 12] refersto The DiffServ working group,http://www.ietf.org/html.charters/diffserv-charter.html, and [Non-patentdocument 13] refers to IP Mobility Support, RFC 3220,http://www.ietf.org/rfc/rfc3220.txt, respectively.

DISCLOSURE OF THE INVENTION

Since the WLAN is not allowed to have direct access to the mobileterminal's subscription information, the home network needs to have analternative way to provide the WLAN necessary for serving the mobileterminal. This invention presents a rule-based solution. A rule engineis placed in the WLAN, and it controls the service provisioning of theWLAN. The home network of the mobile terminal would send ruleinformation to the rule interpreter collocates with the rule engine thattranslates these rules to WLAN specific control information and feed itto the rule engine to execute, so that the WLAN knows how to serve themobile terminal without compromising the information confidentiality ofthe home network.

Using this rule engine, the home network could also assign certain dataprocessing job for accounting to the WLAN. Therefore, the WLAN couldprocess some data locally before send it back to the mobile terminal'shome network. This could save the valuable network resource for thesignaling path.

In order to protect the identification information of the mobileterminal, a certain specific scheme based on combination of symmetricand asymmetric cryptography structure, e.g. public key, and pre-sharedsecret association (security mechanism), is introduced in thisinvention. Using it, the mobile terminal could communicate itsidentification information with its home network without leaking theidentification information which is contained in certain criticalinformation to the WLAN.

The present invention is to be used for the WLAN to inter-work withother networks. The inter-worked network could be another WLAN or apublic cellular network. It is easy to deploy the invention in both ofthe cases. The invention is to be used for two purposes, the useridentification and critical information protection, and access control.

To use the present invention for user identification and criticalinformation protection, the implementer just need to make the messagesthat needs protection to be formed and encrypted based on the schemedescribed in the invention, e.g. the message between the mobile terminaland WLAN access point; between the access point and home domain servers.These messages are not bound to any underlying transport protocols.Therefore, they could be delivered using any proper method which dependson deployment requirements. For example, in an IEEE802.11 system, themessage on the air interface could be transferred on top of the EAPOL(EAP over LAN), and in an IP network, the message between the accesspoint and home network servers could be transferred on top of DIAMETER[Non-patent document 10].

To make each scheme work, before deployment, the mobile terminal musthave the mobile user's home domain server public key. This key should beidentified with an index string or number. This information could bestored in the user's SIM card, or to be distributed and manually inputbefore first time use. Since the invention has the method for updatingthe keys, it is easy to manage the key. It could also be used inconjecture with other key management schemes as a supplementary.

Furthermore, when using the invention for the inter-working accesscontrol, implementer needs to place an interpreter in the WLAN asdescribed in the invention. This interpreter would convert the rulessent from the user's home network to the WLAN specific command withproper parameters. This way, the home network does not need to maintainany information of the WLAN specific technologies. The interpreter couldalso make default local management decisions when the user's homenetwork is not accessible or not able to make decisions, for example,allow the access to certain local WLAN resource. This could keep theservice interruption to the minimum in case of signaling failure.

The rule interpreter could also send accounting information back to theuser's home domain according to the specific rules set by the homedomain rule server. The accounting attributes gathered could beconfigured by the rule server based on its needs. The rule interpretercould also be configured to support the real-time monitoring and batchaccounting easily by issuing commands from the rule server.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating an example message sequence for WLANinter-working. This diagram gives an example sequence for the WLANinter-working that uses the message format for signaling with useridentification information protected, and achieve mutual authenticationbetween the mobile terminal, access point and the home network servers;

FIG. 2 is a diagram illustrating an example message format 1 for amobile terminal sending information to Access Point. This diagram givesan example implementation of the message format to be used for themobile terminal transferring information to the access point;

FIG. 3 is a diagram illustrating an example message format 2 for AccessPoint sending information to Home Domain Server. This diagram gives anexample implementation of the message format to be used for the accesspoint transferring information to the home domain server;

FIG. 4 is a diagram illustrating an example message format 3 for HomeDomain Server sending a message to Central Server. This diagram gives anexample implementation of the message format to be used for the homedomain server transferring information to central server;

FIG. 5 is a diagram illustrating an example message format 4 for CentralServer replying to Home Domain Server. This diagram gives an exampleimplementation of the message format to be used for the central servertransferring information to home domain server;

FIG. 6 is a diagram illustrating an example message format 5 for HomeDomain Server replying to Access Point. This diagram gives an exampleimplementation of the message format to be used for the home domainserver transferring information to the access point;

FIG. 7 is a diagram illustrating an example message format 6 for AccessPoint replying to a mobile terminal. This diagram gives an exampleimplementation of the message format to be used for the access pointtransferring information to the mobile terminal;

FIG. 8 is a diagram which provides an easy-to-understand summary of amessage flow between MT-AP-Home Domain Server-Central Server and itsassociation in configuration between each message;

FIG. 9 is a diagram which provides an easy-to-understand summary of amessage flow in the reverse order of the flow in FIG. 8 and itsassociation in configuration between each message;

FIG. 10 is a diagram illustrating an example of variant scenario forWLAN inter-working. This diagram gives a variance of the scenario forthe WLAN inter-working that uses a virtual terminal for access theuser's credential and subscription for inter-working, and make theservice available to WLAN devices;

FIG. 11 is a diagram illustrating an example framework for theinter-working between WLAN and other networks. This diagram gives anexample implementation of the framework for WLAN inter-working that usesthe rule interpreter for localizing access control rules; and

FIG. 12 is an example operation sequence for the inter-workingframework. This diagram gives an example operation sequence in the WLANwhen the rule interpreter is deployed.

BEST MODE FOR CARRYING OUT THE INVENTION

Embodiments of the present invention will be described in detail belowwith reference to the accompanying drawings.

An apparatus and methods for controlling policy (arrangements related tocommunications) in WLAN inter-working is disclosed in this section. Tohelp understand the invention, the following definitions are used:

A “WLAN” refers to wireless local area network. It contains arbitrarynumber of devices in order to provide LAN services to mobile terminalsthrough wireless technologies;

A “Mobile Terminal” refers to a device used for accessing the serviceprovided by the WLAN and other networks through wireless technologies;

A “Home Network” refers to the network where the MT originally comesfrom in the inter-working scenario. It is the place the MT's servicesubscription information is stored;

A “Network Element” refers to any functioning device in the network thatcan carry out information processing;

A “Rule Engine” refers to a network element that carries out the rulesset by the rule server and interpreted to the local specific commands bythe rule interpreter;

A “Rule Interpreter” refers to a network element that reads in the rulesgiven by the rule server, and translates them to local technologiesspecific commands with appropriate parameters and feeds to the ruleengine to carry out;

A “Rule Server” refers to a network element that sends relevant rulesets to the rule interpreter and rule engine base on request orunsolicited;

An “Air Interface” refers to any radio access technologies for themobile terminal to access the WLAN;

A “Stream” is a gathering of packets transferred in the network thathave certain attributes in common;

A “Traffic” is a gathering of streams transferred in the network;

A “Flow” refers to the data path and the network resources needed forthe data path used in delivering the stream;

“QoS” refers to the term Quality of Service of a data streams ortraffic;

“Message” refers to the information exchanged between the NetworkElements for the purpose of Inter-working control;

“Operation Sequence” refers to a series of Message exchanged betweencertain specific Network Elements in certain specific order forInter-working control;

“Upper Layer” refers to any entity on top of the current entity thatprocess the packet passed to it from the current entity.

In the following description, for purposes of explanation, specificnumbers, times, structures, protocol names, and other parameters are setforth in order to provide a thorough understanding of the presentinvention. However, it will be apparent to anyone skilled in the artthat the presented invention may be practiced without these specificdetails. In other instances, well-known components and modules are shownin block diagram in order not to obscure the present inventionunnecessary.

EMBODIMENT 1

For inter-working between the WLAN and other networks, a few majorissues need to be solved. These include Authentication, Authorization,and Accounting (hereafter referred to as AAA), QoS provisioning, andmobility control. Large parts of the issues desire a policy-basedsolution, e.g. authorization/admission control, QoS and mobilityfunction deployment, etc.

The present invention provides such a solution for those WLANinter-working related problems using a policy-based framework. Thenetwork inter-worked with could be of any type, e.g. 3G Networks,another WLAN network, or some proprietary network.

In course of the inter-working message exchanges, the identificationinformation of the mobile user is required to be provided for the AAApurpose. This information should be available only to the intendednetwork elements (e.g. AAA server). Otherwise, the security of thenetwork would be compromised, and user's location information would berevealed to possible malicious persons.

Accordingly, the present invention presents a method for concealing theinformation from unauthorized party using hierarchical encryption, andasymmetric cryptography. Since no prior security association set up isneeded for this method, it could be useful in the authenticationprocess.

For a thorough understanding of the invention, here below, someoperation sequences and information data structures used for the messageexchanges are given. Some named protocols are used for illustration, butit does not preclude the use of other protocols for the same purpose,and it's not an indication of the recommendation of this invention.Certain data structures are used, and they only serve as an example ofthe implementation of the present invention. It is obvious to the personskilled in the art that in real implementation, new information could beadded, and certain part could be omitted depending on the actualsituation they are used in.

FIG. 1 is a diagram illustrating the operation sequence according toEmbodiment 1 of the present invention. In this embodiment, anexplanation is given taking an example of a case where communications isconducted between a mobile terminal and a central server.

As shown in the FIG. 1, the Mobile Terminal (MT), as marked by literal101, is connected to the Access Point (AP), as marked by literal 102, inthe WLAN through the Air Interface, as marked by literal 106. Messagesare transmitted from the Access Point (102), through the Inter-workingInterface, as marked by literal 107, and a series of IntermediateServers/Proxies, as marked by literal 103, to the Home Domain Server ofthe mobile user, as marked by literal 104. For scalability reasons, theAAA process could happen at the Home Domain Server (104), or at aback-end server (Central Server) as marked by literal 105. When the HomeDomain Server (104), and the Central Server (105) are collocated, themessage exchanges are through internal interface, and thus does not needto know the exact message format.

In the example implementation, it is assumed that the Mobile Terminal(101) has a relatively permanent security association with the CentralServer (105). This could be the IMSI related, for example for the 3Gterminals. It is also assumed that the Home Domain Server (104) has apublic-key and private-key pair for the asymmetrical cryptography scheme[Non-patent document 11], and the Mobile Terminal (101) has thepublic-key. This information could be distributed to the users at thesubscription time, e.g. stored in the SIM card like device, or given tothe user and to be keyed into the terminal to use, or to be put on apublic accessible server and to be downloaded before use.

As shown in FIG. 1, the operation starts with the Mobile Terminal (101)sending a message to the Access Point (102) through the Air Interface(106).

The message is of format Msg1, which is shown in FIG. 2. The message isto be transported by different mechanisms depending on which WLANtechnology is used on the Air Interface (106). For example, inIEEE802.11, this could be carried by EAP over Ethernet [Non-patentdocument 11], and in HiperLAN/2, this could be over RLC messages. Themessage itself does not bind to any underlying technologies.

The example implementation of the message shown in FIG. 2 contains 10parts (201-210). It is obvious to anyone skilled in the art that in realapplication, more information could be incorporated into the necessaryfields, and some unnecessary could be removed depending on actualdeployment situations. For the convenience of presentation, messagefields are introduced in certain sequence. In actual implementation, thefields at the same encryption level could be put in any order. Eachfield could have a fix-width identifier to indicate its contents, and alength field to indicate its actual length.

The message begins with the WLAN Specific Local ID field, as marked byliteral 201. This will contain the information to identify the MobileTerminal (101) in the local WLAN context. For example, in the IEEE802.11networks, this could be the Ethernet address of the mobile terminal, andin the HiperLAN/2 networks, this could be the MAC ID assigned to theMobile Terminal (101).

A Challenge Message to AP field goes right after the above field, asmarked by literal 202. It would contain some random generated string ornumber by the Mobile Terminal (101). The Access Point (102) is supposedto generate a reply using this string together with the security keys toverify itself to the Mobile Terminal (101). The scheme used to generatethe reply could be any message authentication scheme, for exampleHMAC-MD5 [Non-patent document 12]. The security key used is to becarried by the returning messages from the Home Domain Servers (104).

An Expected Result for Network Challenge Message field, as marked byliteral 203, comes next. This field contains the reply that the AccessPoint (102) should receive from the Home Domain Server (104). In theinter-working environments, the Access Points (102) would possiblyinter-work with multiple domains. In order for the Access Point (102) toverify that a reply is from the legitimate server for the MobileTerminal (101), contents in the field could be compared with thecorresponding results contained in the reply messages.

Following that is the Home Domain Info field, as marked by literal 204.This field contains the information to identify the home network of theMobile Terminal (101). Such information would be used by the AccessPoint (102) and other intermediate nodes to route the message to theproper AAA server for processing the Mobile Terminal's AAA information.The domain information could be in the form of a DNS domain name orNetwork Access Identifier (NAI) in the form of user@domain.name. Or, itcould be straight the IP address of a server the message destined to.

Contained also in the field is the index of public key of the HomeDomain Server (104) used for encrypting the user identificationinformation. Since the Home Domain Server (104) might be using a fewpairs of public-private-key at the same time, it is necessary for theMobile Terminal (101) to indicate which key pair is employed to encryptthe current message.

The index could be a number or a string depending on implementationrequirements. The Home Domain Server (104) would use certain hashfunction, for example, to convert it to the actual value to retrieve thekey pair. The index information is embedded in the domain informationfiled. For example, if the NAI is used to carry the domain information,the user part of the NAI could be used to hold the key index, since theactual user ID is not needed here. A Public Key of MT field, as markedby literal 205, is also included in the message. This is for the HomeDomain Server (104) or the Access Point (102) to securely send messageto the Mobile Terminal (101) without get ear-dropped by other entities.

Up to here, all the above fields (201-205) are encrypted only with thepublic key of Access Point (102) to prevent eardrop, and therefore areaccessible by the Access Point (102). The public key of Access Point(102) could be distributed to the Mobile Terminal (101) by periodicalbroadcasting.

On the other hand, from here, all the following fields (206-209) areencrypted with the public key of Home Domain Server (104) by the MobileTerminal (101). They are not available to the Access Point (102), andany nodes in between. Access Point (102), and IntermediateServers/Proxies (103), could use the Home Domain Info (204) to forwardthe message to the proper server.

Once received by the server, it would use the private key in the pairindicated by the key index contained in the Home Domain Info (204) todecrypt the message and obtain the necessary information. This part ofthe message, marked by literal 206 through 209 should be copied directlyby the Access Point (102) to the messages sending to the Home DomainServer (104), as marked by literal Msg2 in FIG. 1.

A security Field, as marked by literal 210, is contained in the messagefor protection of the integrity of the information. In implementation,this could be, for example, the message digest computed using theHMAC-MD5 scheme.

As shown in FIG. 1, after receiving the message, Msg1, the Access Point(102) would extract the necessary information, and form another messageMsg2, and send it to the Home Domain Server (104) through possibleIntermediate Servers/proxies (103). As the number of available WLANtechnologies is increasing quickly, the technologies used forinter-connecting them, as marked by literal 107, could vary largely. Theexample used here for illustration is assuming an IETF IP basedtechnology is employed. However, it is obvious to anyone skilled in theart that the invention is intended to be used with any underlyingtechnologies. With certain modification/adaptations, it could be used onother non-IP based technologies, and even on top of those proprietaryprotocols.

FIG. 3 shows the message format for Msg2.

The message starts with the AP and WLAN Address Field, as marked byliteral 301. This information is needed for the routing of the replymessages. Format of this information is not limited. For example, asimple way is to use the Access Point (102)'s IP address if it has one.Otherwise, the AP identifier, and the address of the WLAN Gateway willbe required. Right after this is the WLAN Specific ID field, as markedby literal 302. This field is the same as that in message format 1, asmarked by literal 201.

All the above information is for the network nodes to identify theMobile Terminal (101), and thus to establish a return route. Since theWLAN Specific ID (302) is a temporary ID and only has meaning in theWLAN context, it will not lead any information about the Mobile Terminal(101)'s actual identification information. As stated above, these fieldsshould be accessible by possible all the nodes along the path, and thusshould not be encrypted with special techniques. If the connections arepoint-to-point, or no reverse direction routing is necessary, thisinformation could be protected by a security mechanism shared by theends of the connections.

It is obvious that fields 303 through 308 are taken directly from thoseof Msg1, in which named 204 through 209. Fields 303, Home Domain Info isused for routing the message to Home Domain Server (104), if there areintermediate nodes exits.

Public Key of MT field, as marked by literal 304, is used to propagatethe public key of the Mobile Terminal (101), so that the reply messagecould be protected if required. In order to verify the legitimacy of thekey, a check sum, e.g. the fingerprint of the key should be provided ina secure way. This could be achieved by put the fingerprint in the userdata, which is protected by the security mechanism between the user andthe server keeping the subscription information.

Field 305 to 308 are meant to be read only by the Home Domain Server(104). Therefore, they are encrypted and protected by the public key ofthe Home Domain Server (104), and not accessible by any intermediatenetwork elements.

A Home Domain Specific User ID field, as marked by literal 305, followsthe MT key field. This is the User ID assigned to the mobile user by itshome network. It is used to unique identify the user in the homenetwork's context. If a user has a NAI in the form ofuserID@home.domain, this identifier corresponds to the userID partbefore the @. This Home Domain Specific User ID is not permanent. Thehome domain could assign a new identifier to the Mobile Terminal (101)by embedding it in the reply messages.

After receiving the message, the Home Domain Server (104) will check theHome Domain Info field (303), and find out the index of the public keyused by the Mobile Terminal (101) to encrypt the message. Then, it willuse the corresponding private key in the key pair to decrypt themessage, and get the User ID information. If the user subscriptioninformation is stored at the server or inside the home domain, it shouldhave the method to map this User ID information to the record entry forthe user, and therefore to decrypt the reset of the message and dofurther processing.

Otherwise, if these are all controlled by another central server, or thehome domain outsourced the AAA process to some outside server, the HomeDomain Server (104) will forward the rest of the message to that serverwith the User ID attached. The rest fields of the message are encryptedby the security mechanism associated with the user subscriptioninformation, i.e. the permanent identifier. Therefore, this part of theinformation could only be retrieved by entities that have the usersubscription information.

The first field is the Network Challenge Message field, as marked byliteral 306. This is the randomly generated information by the MobileTerminal (101). It is used for the Mobile Terminal (101) to verify theauthority of the origin of the reply messages. The network side, e.g.the Central Server (105), should use a key derived from the user'ssubscription information to produce a reply for the Mobile Terminal(101) based on this challenge. Challenge reply should be embedded in thereply message. The network side should also generate a reply for theAccess Point (102), to prove that it's the legitimate source for sendingthe reply. The reply for the Mobile Terminal (101) and the Access Point(102) could be the same or different depending on the implementationrequirements.

After the Network Challenge Message field (306) is the Permanent User IDfield, as marked by literal 307. This field contains the information topermanently and globally identify the user. It would remain constantduring the user's entire subscription period. Using this information,user could be traced and subscription information could be retrievedfrom the database. This field is included for the cases when thesubscription information is not stored in the Home Domain Servers (104).It could be also used by the server to verify the authority of theMobile Terminal (101) by comparing this ID with the identificationinformation mapped from the Home Domain Specific User ID.

Following the ID field is the User Data field, as marked by literal 308.This field contains the data from the Mobile Terminal (101) for the AAAsessions. In real implementation, this field could be protected bycertain mechanism that uses the user's security mechanism derived fromthe subscription information. It could also contain the fields thatprotect the integrity of the information.

At the end of the message is the Security Field, as marked by literal309. This field contains the information to protect the integrity of thewhole message. The actual contents included depending on the deploymentrequirement.

When the Home Domain Server (104) and the Central Server (105) arecollocated, the Home Domain Server (104) would be able to do all thesame processing as done by Central Server (105), and to reply themessage directly to the Access Point (102). When they are notintegrated, i.e., the actual user information is not at the Home DomainServer (104), the server needs to forward the message to the CentralServer (105) as shown in FIG. 1, using message Msg3.

The example implementation of Msg3 is shown in FIG. 4.

The message starts with the Home Domain Info field, as marked by literal401. This would contain the information for the Central Server (105) toidentify the Home Domain Server (104). This is to assume that theCentral Server (105) and the Home Domain Server (104) are not in thesame domain. Followed this field are the Network Challenge Messagefield, as marked by literal 402, the Home Domain Specific User ID field,as marked by literal 403, Permanent User ID field, as marked by literal404, and the User Data field, as marked by literal 405.

The Network Challenge Message field (402) and Home Domain Specific UserID field (403) contain the decrypted information from the Msg2.

The Permanent User ID field (404) and User Data field (405) are copieddirectly from the Msg2's corresponding fields. These two fields areencrypted with the security key derived from the subscriptioninformation by the Mobile Terminal (101).

At the end of the message is the Security Fields, as marked by literal406. This is for protecting the integrity of the message using thesecurity mechanism shared by the Home Domain Server (104) and theCentral Server (405). After receiving the message, the Central Server(105) needs to decrypt the encrypted fields, and retrieve theinformation and do the proper process.

An example implementation of the reply message, Msg4, is shown in FIG.5.

The message starts with the Home Domain Info field, as marked by literal501. This contains the information for identify the Home Domain Server(104), in case these two servers are not directly connected. Home DomainSpecific User ID field, as marked by literal 502, is used to contain theinformation for identify the Mobile Terminal (101) to the Home DomainServer (104), so that the Home Domain Server (104) knows where the replymessage should be forwarded to.

The Central Server (105) should also calculate two security relatedreplies. The first is the AP Response Key, as marked by literal 503.This key will be delivered to the Access Point (102) for it to generatea reply to the AP Challenge Message. The key is derived from the mobileuser's subscription information, and therefore is also available at theMobile Terminal. The other one is the Network Challenge Message Responsefor AP, as marked by literal 504. This would be delivered to the AccessPoint (102) too.

And the Access Point (102) will compare it with the Expected Result forNetwork Challenge Message (203), and to verify the authority of thesource of the reply. These two fields are protected only by the securitymechanism shared by the two servers.

Following these two fields is the Network Challenge Message Response forMT, as marked by literal 505. This is for the server to authenticateitself to the Mobile Terminal (101), and should be delivered to theMobile Terminal (101).

Next, it is the Permanent User ID field, as marked by literal 506. Thisis for the Mobile Terminal (101) to check whether the message is for it.

The next field is the User Data, as marked by literal 507. This containsthe AAA related reply from the server. Actual contents will depend onthe operation carried on in the AAA session. For example, it couldcontain the new home domain specific user ID assigned to the mobileuser. The above three fields, 505, 506, and 507, are encrypted with thesecurity mechanism between the Central Server (105) and the MobileTerminal (101) derived from the subscription information. Therefore,they are only accessible by the Mobile Terminal (101).

The last field in the message is the Security Field, as marked byliteral 508. This field contains the information for protecting theintegrity of the whole message using the security mechanism sharedbetween the Home Domain Server (104) and the Central Server (105).

After receiving the message from the Central Server (105), the HomeDomain Server (104) will extract the necessary information and processaccordingly. A new message would be formed and forwarded to the AccessPoint (102) through the same route or different path depending on theimplementation requirement, as marked by Msg5 in FIG. 1. The processingtaken place in the Home Domain Server (104) includes mapping the user IDto the WLAN specific ID and WLAN address. These are simply theinformation contained in the corresponding message from the Access Point(102).

An example implementation of the message format for Msg5 is shown inFIG. 6.

The message starts with the AP and WLAN Address field, as marked byliteral 601. This field contains the information for identifying theAccess Point (102) in the WLAN that the mobile user associated with. Theaddress information is available in the Msg2 as shown in FIG. 3. TheHome Domain Server (104) could maintain a table of the addresses sortedby the user ID. The table gets updated when the server receives a newmessage for that user ID, and thus could be used in the forming ofcorresponding reply message. The above part of the message is requiredfor routing it to the correct terminal, and thus should not beencrypted.

Following this filed is the WLAN Specific Local ID field, as marked byliteral 602. It contains the information for the Access Point (102) toidentify the Mobile Terminal this message concerning to. This ID is alsoavailable in the Msg2, and it could be retrieved using the same methodas that for the AP and WLAN Address (601).

Next field in the message is the AP Response Key field, as marked byliteral 603. This contains the information for the Access Point (102) togenerate responses to the Mobile Terminal (101)'s challenge. Thecontents are copied directly from the same field in Msg4, as marked byliteral 503.

Following that is the Network Challenge Message Response for AP field,as marked by literal 604. This field contains the response computed bythe Central Server (105), and is for the Access Point (102) to verifythe legitimacy of the Central Server (105). It could also be used by theHome Domain Server (104) to indicate the AAA process success/failurestatus to the Access Point (102). It is also copied directly from thefield in Msg4, as marked by literal 504. The above fields are only meantto be accessed by the appointed Access Point (102), and therefore shouldbe protected by the security mechanism shared between the Home DomainServer (104) and Access Point (102), for example, encrypted by the AP'spublic key.

Next in the message is the New Home Domain Server Public Key field, asmarked by literal 605. This field is optional, and is used only when theHome Domain Server (104) need to change its public key. The informationcontained includes the new key, and the index for that key.

This field and the following fields, 606 to 608, are only to be accessedby the Mobile Terminal (101), therefore, should be protected by thepublic key of the Mobile Terminal (101), which is send to the HomeDomain Server (104) in message Msg2.

In order to verify the legitimacy of the new key, a checksum, e.g. thefingerprint of the key should be provided in a secure way too. Thiscould be achieved by put it in the user data field, which is protectedby the security mechanism between the user and the server keeping thesubscription information. In case of a separate central server, the HomeDomain Server (104) could attach the fingerprint to the message Msg3that sends to the Central Server (105), and ask the Central Server (105)to include it in the user data field of the return message. It isobvious to anyone skilled in the art that the field could also be usedto carry key generation material instead of the real key. The real keycould be derived at the MT side through old key or some subscriptioninformation, and thus provide better protection.

Following that is the Network Challenge Message Response for MT field,as marked by literal 606. This field contains the challenge messageresponse generate by the Central Server (105) for verify its identity tothe Mobile Terminal (101).

Next is the Permanent User ID field, as marked by 607, and the User Datafield, as marked by literal 608. These fields are all generated by theCentral Server (105), and are copied directly from the correspondingfields in Msg4, as marked by literal 505 to 507. They are protected bythe security mechanism between the Central Server (105) and the MobileTerminal (101) derived form the user's subscription information.

The last field of the message is the security field, as marked byliteral 609. This field is used to carry the information to protect theintegrity of the entire message using the security mechanism shared bythe Home Domain Server (104) and the Access Point (105).

After receiving the message, the Access Point (102) will extract therequired fields, such as the 602, 603, and process it. A new messagewill be generated and be forwarded to the Mobile Terminal (101) carryingthe reset of the fields in the message Msg5.

An example implementation of the new message format for Msg6 is shown inFIG. 7.

The message starts with the WLAN Specific Local ID, as marked by literal701. This is for the Mobile Terminal (104) to check whether the messageis sent to it. This field needs not to be encrypted. The actual contentof this field depends on the technology used; e.g. in IEEE802.11network, this could be the 48 bit Ethernet address of the terminal, andin HiperLan/2 network, this could be the terminal's MAC ID assigned bythe Access Point (102).

Following that is the AP Challenge Message Response field, as marked byliteral 702. This contains the challenge computed by the Access Point(102) using the key sent from the Central Server (105) in Msg5, asmarked by literal 603. The Mobile terminal (101) would use thischallenge to verify the legitimacy of the Access Point (102). This fieldand the following fields, 703 to 705, should only be access by theintended receiver, and therefore should be encrypted by the public keyof that Mobile Terminal (101).

Next field in the message is the Network Challenge Message Response forMT, as marked by literal 703. This field contains the response generatedby the Central Server (105) using the security mechanism shared with theterminal. It is used to authenticate the network to the Mobile Terminal(101).

Following that is the Permanent User ID field, as marked by literal 704.This information is used by the Mobile Terminal (101) to further verifythat the message is sent to the Mobile Terminal (101) itself.

The User Data field, as marked by literal 705, contains the AAA relatedinformation replied by the Central Server (105). It is used for AAAprocessing. The above fields are generated by the Central Server (105),and should be encrypted and protected by the security mechanism sharedby the Mobile Terminal (101) and the Central Server (105).

The last field in the message is the Security Field, as marked byliteral 706. This field contains the necessary information forprotecting the integrity of the entire message.

FIG. 8 is a diagram which provides an easy-to-understand summary of amessage flow between MT-AP-Home Domain Server-Central Server and itsassociation in configuration between each message which are describedabove. FIG. 9 is a diagram which provides an easy-to-understand summaryof a message flow in the reverse order of the flow in FIG. 8 and itsassociation in configuration between each message. The above descriptiongives an example of the simple message exchange between the MobileTerminal (101) and the AAA servers using the present invention.

In this way, according to this embodiment, when exchanging messages withthe party on the other end of communications through some networkelements (relay stations), each field which makes up a message isrespectively subjected to encryption using the public key of eachnetwork element requiring each field. That is, each field making up amessage is separately encrypted by using a security mechanism(encryption scheme) which is effective in between each network elementrespectively.

Specifically, when a mobile terminal transmits a message to a server,the part of the message containing the identification information of themobile user is subjected to encryption by using the public key of theserver, whereas the remaining part of the message is subjected toencryption by using the public key of the network element on itscommunications path. Alternatively, the part of the message containingthe identification information of the mobile user is subjected toencryption by using a key derived from the subscription information ofthe mobile user, and such an encrypted message is further subjected toencryption by using the public key of the server, thereby achievinghierarchical encryption.

That is, by using a combination of the symmetrical and asymmetricalcryptography scheme, the present invention provides a solution forsafely carrying out the AAA process in WLAN inter-working withoutleaking any user identification information to unauthorized entity. Itis useful in preventing the man-in-the-middle attack. Note that it isobvious to anyone skilled in the art that the invention could also beused in a more complicated application with different combination ofmessage sequences.

When deployed, this invention is particularly helpful in preventing theman-in-the-middle attack. For example, when there is a forged AccessPoint standing in between the Mobile Terminal (101) and the actualAccess Point (102), it can only obtain the information about theChallenge Message to AP (202), and Expected Result for Network ChallengeMessage (203). This bogus Access Point (forged Access Point) is not ableto get the right reply to the Challenge Message to AP (202), since thisrequires the key from the actual Home Domain Server (104) of the MobileTerminal (101), and the key will not be forwarded out from the AccessPoint (102). Therefore, it is not able to pretend to be an actual AccessPoint (102) to the Mobile Terminal (101).

The invention is also useful in the situation where there is a maliciousentity break into the link between the Access Point (102) and the HomeDomain Server (104). In this case, this outside entity could not obtainany useful the information in the message sent from the Access Point(102), since the crucial parts of the message are encrypted by the HomeDomain Server (104)'s public key. From the message sent back from theHome Domain Server (104), the entity could not obtain any usefulinformation either, since it is encrypted by the AP's public key.

FIG. 10 shows a variation example of WLAN inter-work scenario of thepresent invention.

In this scenario, the user credential and subscription information isstored in a Virtual MT, as marked by literal 101 a. The Virtual MT (101a) may be located anywhere in the WLAN, for example may collocate withthe Access Point. The inter-working sequence will start from the VirtualMT (101 a). The message sequence and format could be exact the same asdescribed above. The only difference here is that the Virtual MT (101 a)is no longer connected through an Air Interface (106) to the AccessPoint.

The Access Server as marked by literal 102 a is the entity that controlsthe connection from WLAN to the inter-worked network. Virtual MT (101 a)could connect to the Access Server (102 a) using any interface, e.g.wired, Infrared, Blue-tooth, etc. It is also possible for the Virtual MT(101 a) to collocate with the Access Server (102 a). In this situation,the Msg1, and Msg6 will be used internally, and might not follow theexact format as defined above. Other message sequence and format willnot be affected, and remains the same.

When this Virtual MT (101 a) successfully obtained access to the servicefrom home domain of the subscription, any WLAN Device as marked byliteral 1001 associated with it would also be allowed to use theservice. The security mechanism setup between the WLAN device (1001) andVirtual MT (101 a) could be proprietary, and the security level is to bedecided by the WLAN.

A real world example of this scenario is that a user hosts a WLAN AccessPoint at home, and s/he has one subscription to a public network, e.g. a3G network, and s/he wants all devices at home to be able to access the3G service once authenticated to the Access Point. This could beimplemented using the above described invention by having the Virtual MT(101 a) collocated with Access Point. The Virtual MT (101 a) wouldaccess the user's credential and subscription information, e.g. his/herUICC, and proceed with the inter-work procedure. After that, WLANdevices (1001) could associate to the AP using any method desired by theuser, e.g. a simple password protection, and use the 3G services, e.g.access the IMS service.

It is obvious to anyone skilled in the art that the invention couldscale to multiple AP situations, in which the Virtual MT (101 a) couldcollocate with an AP controller, or the WLAN's Access Server (102 a) tothe inter-worked network. It is also clear that the scheme applies towired devices, i.e. device associated to the AP through wire or otherinterface instead of air interface could also enjoy the 3G services. Incase of multiple virtual terminals exit in the WLAN, each of them shouldgo through the inter-working procedure independently. When one virtualterminal is able to access multi user's information, e.g. acceptmultiple UICC card simultaneously, inter-working procedure for each ofthe user should be carried out independently. Virtual terminal couldcontrol the WLAN device (1001)'s access to the service subscribed by theuser using proprietary means, e.g. password protection, security token,etc.

EMBODIMENT 2

In the inter-working, WLANs need to make decisions based on usersubscription information, e.g. admission control, from time to time.Since this information is stored in the user's home domain, and isgenerally not allowed to be shared, WLANs have to rely on the HomeDomain Servers (104) to issue decisions. Since the home domain might notalways have the detail knowledge of the technologies used in differentWLANs it inter-worked with, the Home Domain Servers (104) are not ableto give exact instructions to the resource management entities in theWLANs. Also, some applications, e.g. admission control, require localnetwork information, and prevent decision making in home domain.

FIG. 11 shows an example implementation of the present invention thatsolves the problem. In the framework, the Mobile Terminal, as marked byliteral 801, is connected to the network through the WLAN functions. TheWLAN functions include the Rule Engine, as marked by literal 802, andRule Interpreter, as marked by literal 803.

The Rule Engine (802) is the executer of the commands from the RuleInterpreter (803). It controls the accessibility of the Mobile Terminal(801), and manages the local network resources. As shown in the FIG. 11,this engine could collocate with the access point in the WLAN, but thisis not mandated. In actual implementation, it could be a separate entitythat has communication channels with the access point. The Rule Engine(802) also has the channel to signaling to the Mobile Terminal (801).

The Rule Interpreter (803) is the entity that receives rules from thehome domain of the mobile user, and interprets them in the WLAN localcontext. It also has the responsibility to report mobile user statusrelated information to its home domain.

The Rule Interpreter (803) receives rules from the Rule Server thatresides outside of the WLAN, as marked by literal 804. There is norequirement for the placement of the Rule Server (804). The Rule Server(804) is required to provide rules that pertain to the mobile user usingthe inter-working service.

It is possible that the Rule Server (804) serves multiple networks thatinter-work with the WLAN. The Rule Server (804) could also be a proxythat interfaces to the WLAN's Rule Interpreter (803), and uses back-endchannels (Back-end Processing, as marked by literal 805) to retrieveinformation from the actual servers.

A typical operation in the example implementation is shown in FIG. 12.

The mobile user would request certain service through the MobileTerminal (801) from the WLAN, as marked by literal ST 9001. The RuleEngine (802) in the WLAN that controls the local resources would querythe Rule Interpreter (803) about the corresponding operations to betaken, as marked by literal ST 9002. The Rule Interpreter (803) wouldcheck in it is local cache if a valid rule set exists applicable to theoperation, as marked by literal ST 9003. If so, it would make a decisionbased on the rules and current network status in the WLAN, and makingcorresponding status feedback if required. This local cache could beimplemented in the physical memory of the interpreter or an externalnon-volatile storage device.

Information stored in the cache would include the rule received from theRule Server (804) in the previous transactions with a time rangeindicating its validity period. Certain indexing information should alsobe included for identifying and retrieving the rule. When a rule'svalidity expired, it should be marked as invalid and be removed in earlyopportunities. A later rule from the Rule Server (804) could alsooverride the rule in the cache. In order for the proper retrieval of therule, certain information defining the rule applicable range is alsostored with it. This could be, for example, the domain information ofthe mobile user that should be using this rule. It is obvious to anyoneskilled in the art that more information could be stored depending onimplementation requirement. The rules are in a very generic form, sinceit is not feasible for the Rule Server (804) to obtain the underlyingtechnology of each WLAN it connected to.

Therefore, the Rule Interpreter (803) needs to derive WLAN specificdecisions with proper parameters from the rules regarding local networkstatus. For example, the rule could be “ALLOW 3 Mbps BANDWIDTH;TIMELIMIT 10 min.” When the WLAN is using HiperLAN/2, this could betranslated by the Rule Interpreter (803) into decisions “allocated nnumber of LCHs for the terminal for uplink and downlink in every m MACframes”, and “send connection tear down command from AP after g numberof MAC frames”, where the n, m, g are calculated from the information ofthe HiperLAN/2 specifications. It is obvious to the person skilled inthe art that the above is only an example, and the rule could be in anygeneric format agreed between the Rule Server (804) and the RuleInterpreter (803) depending on the operation involved. In a case whereother WLAN technique is employed, the Rule Interpreter (803) shouldoperate in the same method as in, for example, IEEE802.11 technique.

In addition, in a case where no available rule exists in the local cacheof the Rule Interpreter (803), the Rule Interpreter (803) transmits arequest to the Rule Server (804) as marked by literal ST 9005. Whenthere are plural Rule Servers (804) connected to the Rule Interpreter(803), or the Rule Server (804) is a proxy, the Rule Interpreter (803)needs to use the mobile user's domain information to decide which serverto use. In a case where there is no reply from the Rule Server (804), orin a case where no rule regarding the request is available at the RuleServer (804), the Rule Interpreter (803) needs to decide the mobileuser's domain information in order to decide which server to use.

Or in a case where there is no reply from the Rule Server (804), or in acase where no rule regarding the request exists, the Rule Interpreter(803) may use certain pre-set default rule sets to make decisions aboutthe operation.

For example, when no information about the user's access range availablefrom the Rule Server (804), the Rule Interpreter (803) could decide tolet it access local intranet only, or access internet resourcesdepending on the trust level of the user's home network to the WLAN.This default rules could be stored in the Rule Interpreter (803)'s localcache or certain external storage that is accessible by the RuleInterpreter (803). It is obvious to anyone skilled in the art that therecould be different rules for different operations.

When the Rule Server (804) received the enquiry from the RuleInterpreter (803), it would search its rule database for thecorresponding rules, as marked by literal ST 9006. When the Rule Server(804) obtained the rules, it would send it to the Rule Interpreter(804), as marked by literal ST 9007. After receiving the rules from theRule Server (804), the Rule Interpreter (803) would update its localcache with the new rule, and interpret it into WLAN specific commands,as marked by literal ST 9008.

The format for transferring the rule needs to be agreed between the RuleServer (804) and the Rule Interpreter (803). This could be donedynamically through sending the rule format definition to the RuleInterpreter (804) from the Rule Server (803). With this definition, theRule Interpreter (803) is able to extract the necessary rule informationfrom the message. In order to achieve this, the Rule Interpreter (803)needs to support a set of operations that could be used to define therules.  Rule_interpretation_operations::={ ADD; SUB; MUL; DIV; AND; OR;EQUAL; CONDITION; NEGOTIATE; ACCEPT; REJECT; STOP; RELOAD; }

Data structure 1 shown above is an example of the operations supportedby the Rule Interpreter (803). An example of the operation list requiredto support rule definition is given in data structure 1. In this, theADD, SUB, MUL, DIV are corresponding to add, subtraction, multiply, anddivide operations in mathematic context. AND, OR, EQUAL are logicaloperations widely used in all computation languages, e.g. the same as“&&”, “”||”, and “==” in C programming language. CONDITION means thatthe rule has conditions to restrain its usage range. NEGOTIATE meansthat a negotiation is required before the actual decision could be made.ACCEPT means to accept the request for operation, and REJECT means toreject the request for operation. STOP means interrupting the currentoperation. RELOAD is for the Rule Server (804) to indicate to the RuleInterpreter (803) to update the definition and re-deploy. It is obviousto anyone skilled in the art that there could be more operationssupported by the Rule Interpreter (803) in the real implementation.

In order to form the rules, the Rule Interpreter (803) also needs to beable to understand a set of basic attribute set. This would be operationand network dependent. To inter-work with different network, the RuleInterpreter (803) in the WLAN only needs to understand the informationthat is used in that network. For example when inter-worked with a 3Gnetwork, the Rule Interpreter (803) needs to know certain basic 3Grelated attributes. Another way is to have the Rule Interpreter (803)and the Rule Server (804) agree on a set of attributes that can form allthe possible information in the inter-worked network. Rule_interpretation_QoS_attributes::={ MaxBandwidth; MinBandwidth;AverageBandwidth; MaxDelay; MaxJitter; MaxPktSize Burst; Filter; Meter;Marker; Dropper; StartTime; StopTime; }

Data structure 2 shown above is an example of the attributes list forQoS rule interpretation. An example of the attributes list that needs tobe supported for the QoS related operation is given in Data structure 2.The MaxBandwidth, MinBandwidth, AverageBandwidth are the attributes forthe bandwidth related information. The MaxDelay, and Maxjitter givesdelay related information about the rule. MaxPktSize gives informationabout the maximum packet size to be supported. The Burst would indicatethe burstness allowed. The Filter is a compound attribute that containsfield such as, source address (origination point address), destinationaddress (termination point address), source port (origination pointport), destination port (termination point port), TOS field, etc. It isused for the distinguishing of the stream to apply the rule from otherstreams. It is obvious to anyone skilled in the art that using theFilter, the rule could be specified to apply for one terminal or a groupof users.

Meter, Marker, and Dropper are compound fields that are specific toDiffServ [Non-patent document 12]. StartTime, and StopTime indicate thestarting and stop time for a certain operation. It is obvious to anyoneskilled in the art that in real implementation there are more attributesto be supported by the Rule Interpreter (803) depending on thetechnology used in the inter-worked network. Using the above attributesand operations supported by the Rule Interpreter (803), the Rule Server(804) could define the format of the rules to be transferred. Forexample, a server needs to define a format as following: Example_QoS_format::= {OPERATION, AVERAGEBANDWIDTH, BANDWIDTH_VAR,TIME_PERIOD}  It could define the format as:  Example_QoS_format_definition::={  OPERATION::=OPERATION; AVERAGEBANDWIDTH::=AverageBandwidth;  BANDWIDTH_VAR::=MaxBandwidth SUBMinBandwidth;  TIME_PERIOD::=StartTime SUB StopTime;  }

Therefore, a QoS related rule could be send as following:

Example_QoS_rule::=[ALLOW; 10 MBps, 100 Kbps, 5 hour}

It is obvious to anyone skilled in the art that there could be morecomplicated combination of the attributes and operations to form rules. Rule_interpretation_mobility_attributes::={ OriginalAddress;CurrentAddress; HomeAgentAddress; LocalAgentAddress; NextAgentAddress;TunnelAddress; LocalAccessAddress; StartTime; StopTime; Filter; }

Data structure 3 shown above is an example of the attributes list formobility rule interpretation. An example of the attributes collectionthat needs to be supported by the Rule Interpreter (803) in order tosupport mobility is given in Data structure 3. The OriginalAddress is,for example, the home address of the Mobile Terminal (801) in MobileIP[Non-patent document 13] context. The CurrentAddress is thecare-of-address in MobileIP's context. The HomeAgentAddress, andLocalAgentAddress are the home agent's address and foreign agent addressin MobileIP's context. The NextAgentAddress could be the agent in nextdomain the Mobile Terminal (801) expected to enter. The TunnelAddress isthe address for tunneling, which is the traffic needs to be routedthrough tunneling. LocalAccessAddress is the address for local AAAservice. StartTime and StopTime are used to indicate the lifetime of theabove information. Filter is the compound attribute that used todistinguish the stream to apply with the rule from other streams.

It is obvious to anyone skilled in the art that the real implementationwould include more attributes in the list, and the definition of theabove attribute would vary depending on the technologies used. Afterinterpreting the rules using the definition sent from the Rule Server(804) at the Rule Interpreter (803), as marked by literal ST 9008, theRule Interpreter (803) would send the detail decisions to the RuleEngine (802) for execution, as marked by literal ST 9009. It is alsopossible for the Rule Interpreter (803) to forward some information tothe Mobile Terminal (801) in case some cooperation is needed at higherlevel to carry out the rule properly. For example, to send the IP layerfilter information, so that the stream would be passed down to theEthernet layer with proper marking. It is also possible for the RuleServer (804) to redefine the rule format by sending a new definition,and then a RELOAD operation rule. This could also be accompanied by timeinformation that makes the updating happen at certain preset time.

In the system, the Rule Interpreter (803) could also be configured tosupport accounting and monitoring. In a normal accountingimplementation, the WLAN need to transfer all the raw data collected tothe home network of the mobile user. This would waste the networkresources since not all the data are needed. And it also poses a largecomputation burden on the accounting server at the home network since itneeds to process all the raw data and acquire desired information.

A way to solve this is to have the WLAN do some local processing first,and send back only the data specified by the home network. Sincedifferent WLAN has different statistics for recording, some preliminaryfiltering is required. The Rule Interpreter (803) would collectcorresponding statistics and convert them into the records that would beuseful in the inter-working. The set of records to be obtained should bebasic sets that could be used to form any further sophisticated records.The Rule Server (804) and the Rule Interpreter (803) should have anagreement on the basic sets, or a common open standard could be adopted,for example the attributes defined in RFC2924. Rule_interpretation_accounting_attributes::={ StartTime; EndTime;CurrentTime; ReportPeriod; BatchReportingTime PacketTransmitted;PacketDropped; ByteTransmitted; ByteDropped; Priority; Bit_rate_average;Bit_rate_Max; Bit_rate_Min; Max_Pkt_size; Min_Pkt_size;Max_Pkt_interval; Min_Pkt_interval; Min_Drop_interval; }

Data structure 4 shown above is an example of the attributes foraccounting rule interpretation. An example of the attributes to besupported by the Rule Interpreter (803) for forming accounting rules isgiven in Data structure 4. These include the basic information thatshould be collected by the Rule Engine (802) and should be available atthe Rule Interpreter (803). The Rule Server (804) would send adefinition of the accounting record desired to the Rule Interpreter(803) using these attributes and the mathematic operations. For example,when the detail records required by the home network are the duration ofthe traffic, the bandwidth used, the bandwidth variance, the drop rateof the packet, the definition of the accounting list send by the RuleServer (804) could be:  Example_accounting_list::={ DURATION::=EndTimeSUB StartTime; BANDWIDTH::=Bit_rate_average;BANDWIDTH_VAR::=Bit_rate_Max SUB Bit_rate_Min;  DROP_RATE_PKT::=  PacketDropped DIV TOTAL_PKT::=[PacketTransmitted ADD PacketDropped]; }

It's obvious to anyone skilled in the art that there would be moreattributes collected by the WLAN than that listed in the example. Theactual information collected would also depend on the technologies usedin the WLAN. When an attribute used for the accounting specification isnot recognized by the Rule Interpreter (803), an error report should besent to the Rule Server (804), so that the error would be noted, or asubstitution could be negotiated. It is also obvious that the abovescheme could be used for status monitoring of the WLAN too. Real-timeaccounting, e.g. accounting for prepaid service, could also beimplemented using the facilities provided above. For example, this couldbe implemented by setting a rule with the condition as following: {STOP;CONDITION ByteTranmitted EQUAL 10 MB}.

The Rule Interpreter (803) would translate this into WLAN specificconditions, e.g. in terms of number of LCHs for a HiperLAN/2 system, andissue a disassociation command to the access point upon the fulfillmentof the conditions. In case of user top up or upgrade of service, a newrule from the Rule Server (804) can override the old one with newconditions. The Rule Interpreter (803) is also allowed to adapt theinterpretation of the rules in case of network condition change in theWLAN. This could happen, for example, when the modulation scheme changeor error rate change in the system occurs so that the formerinterpretation becomes no longer valid. When this kind of situationoccurs, the Rule Interpreter (803) need to adapt the mapping betweenrules and WLAN local parameters so that the service would not beinterrupted, and report the changes to the Rule Server (804). The RuleServer (804) would be able to evaluate the changes and possibly re-issuerules. This way, service interruption due to transient states in WLANcould be avoided.

The 1st aspect of the present invention is a method of protecting mobileuser identification information in a WLAN inter-working, comprising thesteps of: i. performing hierarchical encryption of a message containingthe mobile user identification information with different keys atdifferent encryption levels; ii. using home domain name for assistancein routing the encrypted message to a correct network; and iii. usingtemporary domain specific identifier for further concealing of an actualidentification information of the mobile user.

The 2nd aspect of the present invention is the method of protecting themobile user identification information according to the above procedure,further comprising the steps of: i. using asymmetric cryptography schemefor protection of the mobile user identification information with anintended receiver's key; and ii. using challenge message-responseexchange scheme for a mutual authentication of a mobile terminal and anetwork to protect against attacks.

The 3rd aspect of the present invention is the method of protecting themobile user identification information according to the above procedure,further comprising the steps of: i. sharing the intended receiver'sasymmetric cryptography key with the mobile terminal prior to a start ofmessage exchanges by storing it in a storage device that could beaccessed by the mobile terminal securely; ii. updating the asymmetriccryptography key pair to be used by including a new key in a repliedmessage and encrypted and protected by the current key; and iii.identifying the asymmetric cryptography key pair currently used in theencryption for the identification information protection by embedding aninformation in a domain information.

The 4th aspect of the present invention is the method of protecting themobile user identification information according to the above procedure,wherein a message sequence for the WLAN inter-working is capable ofmutually authenticating the mobile terminal with WLAN, and its homenetwork in one message round trip, the message sequence comprising: i.the mobile terminal sending to the access point a message comprising theencrypted identification information, a mutual authenticationinformation, a mobile user home domain information, and other necessaryinformation; ii. the Access point sending to a mobile user's home domainserver a message comprising the encrypted mobile user identificationinformation, the mutual authentication information, and other necessaryinformation by using the mobile user home domain information; iii. theAccess point receiving from the mobile user's home domain server amessage comprising the mutual authentication information and othernecessary information; and iv. the Mobile terminal receiving from theaccess point a message comprising the mutual authentication informationand other information forwarded by the access point from other servers.

The 5th aspect of the present invention is the method of protecting themobile user identification information according to the above procedure,wherein the message sequence for the WLAN inter-working furthercomprises: i. the Mobile user's home domain server sending to a centralserver a message comprising the mutual authentication information andother information forwarded by the access point from mobile terminal;and ii. the Mobile user's home domain server receiving from the centralserver the message comprising the mutual authentication information andother information to be forwarded to the mobile terminal.

The 6th aspect of the present invention is the method of protecting themobile user identification information according to the above procedure,wherein a set of message format to be used in the message sequence forthe WLAN inter-working comprises: i. mobile user identifier specific tothe WLAN accessible to all network nodes; ii. mobile user's home domaininformation accessible to all network nodes; iii. mobile user'scredential and identification information hierarchical encrypted andonly accessible by the intended receivers; iv. authentication challengeand response encrypted and only accessible by parties involved in themutual authentication; and v. information for message integrityprotection.

The 7th aspect of the present invention is the method of protecting themobile user identification information according to the above procedure,wherein a message format to be used for the WLAN inter-working furthercomprises: i. information for identifying a key used for thehierarchical encryption to the intended receiver; and ii. informationfor generating a new key for the identification information protection.

The 8th aspect of the present invention is the method of protecting themobile user identification information according to the above procedure,that is capable of sharing user's subscription within the WLAN,comprising the steps of: i. arranging one or more virtual terminals thatare able to access the user's credential and subscription informationand carry out the inter-working function as a normal mobile terminalfrom the inter-worked network; ii. using the virtual terminal as agateway for a WLAN device associated with it to access services providedby the inter-worked network; and iii. controlling the service access ofthe WLAN device to the inter-worked network by the virtual terminal.

The 9th aspect of the present invention is the method of protecting themobile user identification information according to the above procedure,further comprising the steps of: i. accessing the one or more users'credential and subscription information simultaneously by the virtualterminal; and ii. sharing these one or more users' subscribed servicesfrom the inter-worked network in WLAN simultaneously.

The 10th aspect of the present invention is a method of inter-working aWLAN with other networks, comprising the steps of: i. executing rulesets, and control resources allocation in the WLAN accordingly by a ruleengine in the WLAN; ii. sending the rule sets from a rule server in thenetwork to a rule interpreter; and iii. interpreting the rules from therule server and convert to a WLAN specific action instruction for therule engine by the rule interpreter in the WLAN.

The 11th aspect of the present invention is the method of inter-workingthe WLAN with other networks according to the above procedure, furthercomprising the steps of: i. locally storing the rules in the WLAN; andii. using default rule sets by the rule interpreter when the rule serveris not available or not able to give relevant rules.

The 12th aspect of the present invention is the method of inter-workingthe WLAN with other networks according to the above procedure, furthercomprising the steps of: i. configuring the translation of the rule atthe rule interpreter by sending the rule definition from the ruleserver; ii. setting a life time range of the rules by including it inthe message from the rule server; and iii. modifying a behavior of therule interpreter and re-deploying by sending new definition andre-deploy message from the rule server.

The 13th aspect of the present invention is the method of inter-workingthe WLAN with other networks according to the above procedure, for realtime status reporting in the WLAN inter-working schemes, furthercomprising the steps of: i. the rule server's specifying the informationand the format to be reported from the rule interpreter; ii. the ruleinterpreter's forming the information in the format set by the ruleserver from the actual WLAN specific status information; where theinformation for the rule interpreter allowing mathematical operations,logic operations and operational commands to execute the mathematicaland logical operations to be carried out; and the operations commandsinclude conditional operations to be carried out, timing information forthe operations to be executed, admissions control of operations andre-executions of the operations.

The 14th aspect of the present invention is the method of inter-workingthe WLAN with other networks according to the above procedure, furthercomprising the steps of: i. automatically adapting the translation ofthe rules by the rule interpreter in case of changes in network statusand network resource availability in the WLAN; and ii. reporting theadaptation made at the rule interpreter to the rule server.

The 15th aspect of the present invention is the method of inter-workingthe WLAN with other networks according to the above procedure, furthercomprising the steps of: i. configuring individual terminal related QoSprovisioning in the WLAN from the rule server; and ii. configuring agroup of terminals related QoS provisioning in the WLAN from the ruleserver.

The 16th aspect of the present invention is the method of inter-workingthe WLAN with other networks according to the above procedure, furthercomprising the steps of: i. configuring individual terminal relatedtraffic routing and mobility information in the WLAN from the ruleserver; and ii. configuring a group of terminals related traffic routingand mobility information in the WLAN from the rule server.

The 17th aspect of the present invention is the method of inter-workingthe WLAN with other networks according to the above procedure, furthercomprising the steps of: i. doing local accounting at the rule engineaccording to the WLAN specific requirement; ii. managing the ruletranslation according to the accounting results at the rule interpreter;iii. configuring the accounting report format at the rule interpreter bythe rule server; and iv. forming the accounting report in the format setby the rule server from the WLAN specific statistics at the ruleinterpreter.

The 18th aspect of the present invention is the method of inter-workingthe WLAN with other networks according to the above procedure, furthercomprising the steps of: i. supporting real-time accounting for pre-paidsubscription by setting local accounting criteria at the ruleinterpreter; and ii. supporting batch accounting by setting accountingrules at the rule interpreter.

The 19th aspect of the present invention is an apparatus for protectingmobile user identification information in a WLAN inter-working,comprising: i. means for performing hierarchical encryption of a messagecontaining the mobile user identification information with differentkeys at different encryption levels; ii. means for using home domainname for assistance in routing the encrypted message to a correctnetwork; and iii. means for using Temporary domain specific identifierfor further concealing of an actual identification information of themobile user.

The 20th aspect of the present invention is the apparatus for protectingthe mobile user identification information according to the aboveconfiguration, further comprising: i. means for using asymmetriccryptography scheme for protection of the mobile user identificationinformation with an intended receiver's key; and ii. means for usingchallenge message-response exchange scheme for a mutual authenticationof a mobile terminal and a network to protect against attacks.

The 21st aspect of the present invention is the apparatus for protectingthe mobile user identification information according to the aboveconfiguration, further comprising: i. means for sharing the intendedreceiver's asymmetric cryptography key with the mobile terminal prior toa start of message exchanges by storing it in a storage device thatcould be accessed by the mobile terminal securely; ii. means forupdating the asymmetric cryptography key pair to be used by including anew key in a replied message and encrypted and protected by the currentkey; and iii. means for identifying the asymmetric cryptography key paircurrently used in the encryption for the identification informationprotection by embedding an information in a domain information.

The 22nd aspect of the present invention is a system of protecting amobile user identification information, wherein a message sequence for aWLAN inter-working is capable of mutually authenticating a mobileterminal with WLAN, and its home network via an access point in onemessage round trip, the message sequence comprising: i. the mobileterminal sending to the access point a message comprising an encryptedidentification information, a mutual authentication information, amobile user home domain information, and other necessary information;ii. the access point sending to a mobile user's home domain server inthe home network of the mobile terminal a message comprising theencrypted mobile user identification information, the mutualauthentication information, and other necessary information by using themobile user home domain information; iii. the access point receivingfrom the mobile user's home domain server a message comprising themutual authentication information and other necessary information; andiv. the mobile terminal receiving from the access point a messagecomprising the mutual authentication information and other informationforwarded by the access point from other servers.

The 23rd aspect of the present invention is the system of protecting themobile user identification information according to the aboveconfiguration, wherein the message sequence for the WLAN inter-workingfurther comprises: i. the mobile user's home domain server sending to acentral server a message comprising the mutual authenticationinformation and other information forwarded by the access point frommobile terminal; and ii. the mobile user's home domain server receivingfrom the central server the message comprising the mutual authenticationinformation and other information to be forwarded to the mobileterminal.

The 24th aspect of the present invention is the system of protecting themobile user identification information according to the aboveconfiguration, wherein a set of message format to be used in the messagesequence for the WLAN inter-working comprises: i. mobile user identifierspecific to the WLAN accessible to all network nodes; ii. mobile user'shome domain information accessible to all network nodes; iii. mobileuser's credential and identification information hierarchical encryptedand only accessible by the intended receivers; iv. authenticationchallenge and response encrypted and only accessible by parties involvedin the mutual authentication; and v. information for message integrityprotection.

The 25th aspect of the present invention is the system of protecting themobile user identification information according to the aboveconfiguration, wherein a message format to be used for the WLANinter-working further comprises: i. information for identifying a keyused for the hierarchical encryption to the intended receiver; and ii.information for generating a new key for the identification informationprotection.

The 26th aspect of the present invention is the system of protecting themobile user identification information according to the aboveconfiguration, that is capable of sharing user's subscription within theWLAN, comprising: i. one or more virtual terminals that are able toaccess the user's credential and subscription information and carry outthe inter-working function as a normal mobile terminal from theinter-worked network; and ii. an apparatus for controlling the serviceaccess of the WLAN device to the inter-worked network by the virtualterminal, thereby the virtual terminal is used as a gateway for a WLANdevice associated with it to access services provided by theinter-worked network.

The 27th aspect of the present invention is the system of protecting themobile user identification information according to the aboveconfiguration, further comprising: i. a virtual terminal that can accessthe one or more users' credential and subscription informationsimultaneously by the virtual terminal; and ii. an apparatus for sharingthese one or more users' subscribed services from the inter-workednetwork in WLAN simultaneously.

The 28th aspect of the present invention is the system of inter-workinga WLAN with other networks, comprising: i. a rule engine in the WLANthat would execute rule sets, and control resources allocation in theWLAN accordingly; ii. a rule database and rule server in the networkthat inter-worked with the WLAN, which would send the rule sets to arule interpreter; and iii. a rule interpreter in the WLAN that wouldinterpret the rules from the rule server and convert to a WLAN specificaction instruction for the rule engine.

The 29th aspect of the present invention is the system of inter-workingthe WLAN with other networks according to the above configuration,further comprising: i. an apparatus for locally storing the rules in theWLAN; and ii. an apparatus for using default rule sets by the ruleinterpreter when the rule server is not available or not able to giverelevant rules.

The 30th aspect of the present invention is the system of inter-workingthe WLAN with other networks according to the above configuration,further comprising: i. an apparatus for configuring the translation ofthe rule at the rule interpreter by sending the rule definition from therule server; ii. an apparatus for setting a life time range of the rulesby including it in the message from the rule server; and iii. anapparatus for modifying a behavior of the rule interpreter andre-deploying by sending new definition and re-deploy message from therule server.

The 31st aspect of the present invention is the system of inter-workingthe WLAN with other networks according to the above configuration, forreal time status reporting in the WLAN inter-working schemes, furthercomprising: i. the rule server which specifies the information and theformat to be reported from the rule interpreter; the rule interpreterwhich forms the information in the format set by the rule server fromthe actual WLAN specific status information; and rule interpreter whichis capable of executing commands including mathematical, logical andrule admission control operations form the rule format set by the ruleserver.

The 32nd aspect of the present invention is the system of inter-workingthe WLAN with other networks according to the above configuration,further comprising: i. an apparatus for automatically adapting thetranslation of the rules by the rule interpreter in case of changes innetwork status and network resource availability in the WLAN; and ii. anapparatus for reporting the adaptation made at the rule interpreter tothe rule server.

The 33rd aspect of the present invention is the system of inter-workingthe WLAN with other networks according to the above configuration,further comprising: i. an apparatus for configuring individual terminalrelated QoS provisioning in the WLAN from the rule server; and ii. anapparatus for configuring a group of terminals related QoS provisioningin the WLAN from the rule server.

The 34th aspect of the present invention is the system of inter-workingthe WLAN with other networks according to the above configuration,further comprising: i. an apparatus for configuring individual terminalrelated traffic routing and mobility information in the WLAN from therule server; and ii. an apparatus for configuring a group of terminalsrelated to traffic routing and mobility information in the WLAN from therule server.

The 35th aspect of the present invention is the system of inter-workingthe WLAN with other networks according to the above configuration,further comprising: i. an apparatus for doing local accounting at therule engine according to the WLAN specific requirement; ii. an apparatusfor managing the rule translation according to the accounting results atthe rule interpreter; iii. an apparatus for configuring the accountingreport format at the rule interpreter by the rule server; and iv. anapparatus for forming the accounting report in the format set by therule server from the WLAN specific statistics at the rule interpreter.

The 36th aspect of the present invention is the system of inter-workingthe WLAN with other networks according to the above configuration,further comprising: i. an apparatus for supporting real-time accountingfor pre-paid subscription by setting local accounting criteria at therule interpreter; and ii. an apparatus for supporting batch accountingby setting accounting rules at the rule interpreter.

The present invention provides a way for protecting the identificationinformation of the mobile user in the message exchange for WLANinter-working. When it deployed, the messages from the mobile user foraccess control could be correctly routed to the proper entity withoutleaking the actual identification information of the user. The presentinvention also provides a method for managing the key information forthe asymmetric cryptography used in identification informationprotection. With all these, the message exchanges are protected fromattacks, especially man-in-the-middle attack.

This invention also includes a method for managing resource controllingin WLAN inter-working by using an interpreter in WLAN. With it applied,the inter-worked network can do the access control of the terminal inWLAN without needing to have the detail technologies knowledge of theWLAN. It also allows the networks to negotiate the way of transferringthe information. Also, when it deployed, the WLAN could be configured todo certain local accounting processing, and report only the desiredinformation back to the inter-worked network. This would save theprecious signaling bandwidth.

This specification is based on the Japanese Patent Application No.2002-299569 filed on Oct. 11, 2002, entire content of which is expresslyincorporated by reference herein.

INDUSTRIAL APPLICABILITY

The present invention pertains to the field of wireless datacommunication. More particularly, this invention relates to theprovision of service in the wireless LAN environment to the mobile usercoming from other networks. It could be used for the inter-working ofthe WLAN to the public radio networks, e.g. 3G networks, or WLANs usingother radio technologies or in another administrative domain. Theinvention is used for the control of the access of the resource of theWLAN for the mobile users, in particular, the authentication,authorization, and accounting issues. It is also targeted for solvingthe problems of QoS (Quality of Service) provisioning and mobilitysupport in the inter-working.

FIG. 1

-   103 INTERMEDIATE SERVER/PROXY-   104 HOME DOMAIN SERVER-   105 CENTRAL SERVER-   106 AIR INTERFACE-   107 INTER-WORKING INTERFACE OF WLAN AND OTHER NETWORK-   OTHER PROCESS-   PROCESSING

FIG. 2

-   PUBLIC KEY OF AP-   PUBLIC KEY OF HOME DOMAIN SERVER-   KEY DERIVED FROM SUBSCRIPTION INFORMATION-   201 WLAN SPECIFIC LOCAL ID-   202 CHALLENGE MESSAGE TO AP-   203 EXPECTED RESULT FOR NETWORK CHALLENGE MESSAGE-   204 HOME DOMAIN INFO-   205 PUBLIC KEY OF MT-   206 SPECIFIC USER ID IN HOME DOMAIN-   207 NETWORK CHALLENGE MESSAGE-   208 PERMANENT USER ID-   209 USER DATA-   210 SECURITY FIELD

FIG. 3

-   PUBLIC KEY OF HOME DOMAIN SERVER-   KEY DERIVED FROM SUBSCRIPTION INFORMATION-   301 AP AND WLAN ADDRESS-   302 WLAN SPECIFIC LOCAL ID-   303 HOME DOMAIN INFO-   304 PUBLIC KEY OF MT-   305 SPECIFIC USER ID IN HOME DOMAIN-   306 NETWORK CHALLENGE MESSAGE-   307 PERMANENT USER ID-   308 USER DATA-   309 SECURITY FIELD

FIG. 4

-   KEY DERIVED FROM SUBSCRIPTION INFORMATION-   401 HOME DOMAIN INFO-   402 NETWORK CHALLENGE MESSAGE-   403 SPECIFIC USER ID IN HOME DOMAIN-   404 PERMANENT USER ID-   405 USER DATA-   406 SECURITY FIELD

FIG. 5

-   KEY DERIVED FROM SUBSCRIPTION INFORMATION-   501 HOME DOMAIN INFO-   502 SPECIFIC USER ID IN HOME DOMAIN-   503 AP RESPONSE KEY-   504 NETWORK CHALLENGE MESSAGE RESPONSE FOR AP-   505 NETWORK CHALLENGE MESSAGE RESPONSE FOR MT-   506 PERMANENT USER ID-   507 USER DATA-   508 SECURITY FIELD

FIG. 6

-   PUBLIC KEY OF AP-   PUBLIC KEY OF MT-   KEY DERIVED FROM SUBSCRIPTION INFORMATION-   601 AP AND WLAN ADDRESS-   602 WLAN SPECIFIC LOCAL ID-   603 AP RESPONSE KEY-   604 NETWORK CHALLENGE MESSAGE RESPONSE FOR AP-   605 NEW HOME DOMAIN SERVER PUBLIC KEY-   606 NETWORK CHALLENGE MESSAGE RESPONSE FOR MT-   607 PERMANENT USER ID-   608 USER DATA-   609 SECURITY FIELD

FIG. 7

-   PUBLIC KEY OF MT-   KEY DERIVED FROM SUBSCRIPTION INFORMATION-   701 WLAN SPECIFIC LOCAL ID-   702 AP CHALLENGE MESSAGE RESPONSE-   703 NETWORK CHALLENGE MESSAGE RESPONSE FOR MT-   704 PERMANENT USER ID-   705 USER DATA-   706 SECURITY FIELD

FIG. 8

-   104 HOME DOMAIN SERVER-   105 CENTRAL SERVER-   Msg 1-   PUBLIC KEY OF AP-   PUBLIC KEY OF HOME DOMAIN SERVER-   KEY DERIVED FROM SUBSCRIPTION INFORMATION-   WLAN SPECIFIC LOCAL ID-   CHALLENGE MESSAGE TO AP-   EXPECTED RESULT FOR NETWORK CHALLENGE MESSAGE-   HOME DOMAIN INFO-   PUBLIC KEY OF MT-   SPECIFIC USER ID IN HOME DOMAIN-   NETWORK CHALLENGE MESSAGE-   PERMANENT USER ID-   USER DATA-   SECURITY FIELD-   Msg 2-   PUBLIC KEY OF HOME DOMAIN SERVER-   KEY DERIVED FROM SUBSCRIPTION INFORMATION-   AP AND WLAN ADDRESS-   WLAN SPECIFIC LOCAL ID-   HOME DOMAIN INFO-   PUBLIC KEY OF MT-   SPECIFIC USER ID IN HOME DOMAIN-   NETWORK CHALLENGE MESSAGE-   PERMANENT USER ID-   USER DATA-   SECURITY FIELD-   Msg 3-   KEY DERIVED FROM SUBSCRIPTION INFORMATION-   HOME DOMAIN INFO-   NETWORK CHALLENGE MESSAGE-   SPECIFIC USER ID IN HOME DOMAIN-   PERMANENT USER ID-   USER DATA-   SECURITY FIELD

FIG. 9

-   105 CENTRAL SERVER-   104 HOME DOMAIN SERVER-   Msg 4-   KEY DERIVED FROM SUBSCRIPTION INFORMATION-   HOME DOMAIN INFO-   SPECIFIC USER ID IN HOME DOMAIN-   AP RESPONSE KEY-   NETWORK CHALLENGE MESSAGE RESPONSE FOR AP-   NETWORK CHALLENGE MESSAGE RESPONSE FOR MT-   PERMANENT USER ID-   USER DATA-   SECURITY FIELD-   Msg 5-   PUBLIC KEY OF AP-   PUBLIC KEY OF MT-   KEY DERIVED FROM SUBSCRIPTION INFORMATION-   AP AND WLAN ADDRESS-   WLAN SPECIFIC LOCAL ID-   AP RESPONSE KEY-   NETWORK CHALLENGE MESSAGE RESPONSE FOR AP-   NEW HOME DOMAIN SERVER PUBLIC KEY-   NETWORK CHALLENGE MESSAGE RESPONSE FOR MT-   PERMANENT USER ID-   USER DATA-   SECURITY FIELD-   Msg 6-   PUBLIC KEY OF MT-   KEY DERIVED FROM SUBSCRIPTION INFORMATION-   WLAN SPECIFIC LOCAL ID-   AP CHALLENGE MESSAGE RESPONSE-   NETWORK CHALLENGE MESSAGE RESPONSE FOR MT-   PERMANENT USER ID-   USER DATA-   SECURITY FIELD

FIG. 10

-   1001 WLAN APPARATUS-   101 a VIRTUAL TERMINAL-   102 a ACCESS SERVER-   103 INTERMEDIATE SERVER/PROXY-   104 HOME DOMAIN SERVER-   105 CENTRAL SERVER-   106 AIR INTERFACE-   107 INTER-WORKING INTERFACE OF WLAN AND OTHER NETWORK-   WLAN FUNCTION-   OTHER PROCESS-   PROCESSING-   WLAN SPECIFIC PROCESS-   WLAN APPARATUS ACCESS TO VIRTUAL TERMINAL'S HOME DOMAIN SERVICE

FIG. 11

-   106 AIR INTERFACE-   107 INTER-WORKING INTERFACE OF WLAN AND OTHER NETWORK-   WLAN FUNCTION-   801 MOBILE TERMINAL-   802 RULE ENGINE (AP)-   803 RULE INTERPRETER-   804 RULE SERVER-   805 BACK-END PROCESSING-   INTER-WORKED NETWORK

FIG. 12

-   WLAN FUNCTION-   801 MOBILE TERMINAL-   802 RULE ENGINE (AP)-   803 RULE INTERPRETER-   804 RULE SERVER-   OTHER PROCESS-   ST 9001 REQUEST-   ST 9002 ENQUIRY-   ST 9003 LOCAL CACHE CHECK-   ST 9005 RULE REQUEST-   ST 9006 RULE SEARCH-   ST 9007 RULE REPLY-   ST 9008 RULE INTERPRETATION-   ST 9009 WLAN DECISION-   ST 9010 RESPONSE

1. A user identification information protection method for encryptingeach field of a message transmitted through at least one relay stationby using encryption schemes which are respectively effective in betweena relay station requiring each field or a party on the other end ofcommunication.
 2. The user identification information protection methodaccording to claim 1, comprising the steps of: encrypting a part of themessage containing identification information of a mobile user by usingan encryption scheme which is effective in between the party on theother end of communication; and encrypting a remaining part of themessage by using an encryption scheme which is effective in between therelay station.
 3. The user identification information protection methodaccording to claim 1, comprising: a first step of encrypting a part ofthe message containing identification information of a mobile user byusing an encryption scheme which is derived from subscriptioninformation of the mobile user; and a second step of further encryptingthe message subjected to encryption in the first step by using anencryption scheme which is effective in between the party on the otherend of communication.
 4. A user identification information protectionmethod comprising the steps of: performing hierarchical encryption ofeach part of a message containing identification information of a mobileuser with keys at different encryption levels respectively; routing theencrypted message to a correct network by using a home domain name; andfurther concealing actual identification information of the mobile userby using a temporary domain specific identifier.
 5. The useridentification information protection method according to claim 4,further comprising the steps of: protecting the identificationinformation of the mobile user having an intended receiver's key byusing asymmetric cryptography; and protecting the identificationinformation against attacks from a third party by using a challengemessage-response exchange scheme for a mutual authentication of a mobileterminal and a network.
 6. The user identification informationprotection method according to claim 5, further comprising the steps of:sharing the intended receiver's asymmetric cryptography key with themobile terminal prior to a start of message exchanges and storing theasymmetric cryptography key in a storage device that could be accessedby the mobile terminal securely; updating the asymmetric cryptographykey pair by including a new asymmetric cryptography key in a repliedmessage encrypted by the current asymmetric cryptography key; andidentifying the asymmetric cryptography key pair currently used in theencryption for the identification information protection by embeddinginformation in domain information.
 7. The user identificationinformation protection method according to claim 4, wherein a messagesequence is capable of mutually authenticating the mobile terminalbelonging to WLAN and its home network in one message round trip,wherein the method comprising the steps of, through the messagesequence: the mobile terminal sending to the access point the encryptedidentification information, mutual authentication information, mobileuser home domain information, and other necessary information; theaccess point sending to a mobile user's home domain server the encryptedmobile user identification information, the mutual authenticationinformation, and other necessary information by using the mobile userhome domain information; the access point receiving from the mobileuser's home domain server the mutual authentication information andother information; and the mobile terminal receiving from the accesspoint the mutual authentication information and other informationforwarded by the access point from other server.
 8. The useridentification information protection method according to claim 7,comprising the steps of, through the message sequence: the mobile user'shome domain server sending to the central server a message comprisingthe mutual authentication information and other information forwarded bythe access point from mobile terminal; and the mobile user's home domainserver receiving from the central server the message comprising themutual authentication information and other information to be forwardedto the mobile terminal.
 9. The user identification informationprotection method according to claim 7, wherein a set of message formatto be used in the message sequence comprises: mobile user identificationinformation specific to the WLAN accessible to all network nodes; mobileuser's home domain information accessible to all network nodes; mobileuser's credential and identification information hierarchicallyencrypted and only accessible by the intended receiver; anauthentication challenge message and response encrypted and onlyaccessible by parties involved in the mutual authentication; andinformation for message integrity protection.
 10. The useridentification information protection method according to claim 9,wherein the message format further comprising: information foridentifying a key used for the hierarchical encryption to the intendedreceiver; and information for generating a new key for protection of theidentification information.
 11. The user identification informationprotection method according to claim 7, comprising the steps of:deploying one or more virtual terminal that is able to access the user'scredential and subscription information and carries out theinter-working function as a normal mobile terminal from the inter-workednetwork; using as a gateway for a WLAN device associated with thevirtual terminal to access services provided by the inter-workednetwork; and controlling the service access of the WLAN device to theinter-worked network by the virtual terminal.
 12. The useridentification information protection method according to claim 11,comprising the steps of: accessing one or more of the users' credentialand subscription information simultaneously by the virtual terminal; andsharing these one or more users' subscribed services from theinter-worked network in WLAN.